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ABSTRACT 


The  Defence  Research  Establishment  Ottawa  is  developing  a  Space -Based 
Radar  Simulation  Laboratory.  Initially,  this  Laboratory  will  consist  of  two 
simulators,  an  SBR  System  Simulator  and  an  Integrated  Surveillance  and 
Interception  Response  System  Simulator.  This  technical  note  describes  both 
simulators  and  the  expected  capability  of  the  Space-Based  Radar  Simulation 
Laboratory.  Details  on  the  development  approach  and  on  laboratory  hardware 
are  provided.  A  high  level  overview  of  the  user  operations  for  the  two 
simulators  is  also  given. 


resume" 


Le  Centre  de  recherches  pour  la  defense,  Ottawa  est  en  train  de 
-  developper  un  laboratoire  de  simulation  pour  un  Radar  Spatial(RS). 

Initialement,  ce  laboratoire  consistera  de  deux  simulateurs,  un  simulateur 
d'un  systfeme  RS  et  un  simulateur  pour  un  systAme  de  surveillance  et 
■*  d' interception  intdgrdes.  Cette  note  technique  ddcrit  les  deux  simulateurs  et 

la  capacity  attendue  d'un  laboratoire  de  simulation  pour  un  Radar  Spatial. 

Les  details  sur  l'approche  prise  pour  le  ddveloppement  et  sur  le  hardware  du 
laboratoire  sont  foumis.  Un  survol  A  un  haut  niveau  des  operations  qu'un 
usager  devra  effectuer  est  inclus  pour  les  deux  simulateurs. 


EXECUTIVE  SUMMARY 


The  Defence  Research  Establishment  Ottawa  is  developing  a  Space -Based 
Radar  Simulation  Laboratory  (SBRSL).  Two  simulators  are  being  developed:  an 
SBR  System  Simulator  and  an  Integrated  Surveillance  and  Interception  Response 

♦  System  (ISIRS)  Simulator.  The  development  of  the  SBRSL  has  been  broken  down 
into  two  phases:  the  Definition  Study  Phase  and  the  Detailed  Design, 
Implementation,  Test  and  Installation  Phase. 

The  development  work  is  now  in  the  second  phase.  The  contractors  will 
be  following  the  intent  of  DoD-STD-2167A.  The  two  simulators  are  being 
designed  and  implemented  using  object-oriented  techniques.  Prototyping  will 
be  used  for  several  aspects  of  the  simulator. 

The  models  that  will  be  included  in  the  simulators  will  initially  be 
simple.  It  is  anticipated  that  additional  work  will  be  carried  out  to  later 
incorporate  more  detailed  models. 

The  running  of  either  simulator  will  consist  of  five  basic  operations: 

•  Simulation  Configuration 

•  Run  Planning 

•  Run  Operations 

•  Data  Analysis 

•  Data  Output 

*  The  Simulation  Laboratory  will  be  used  by  researchers  and  contractors  to 
study  various  design  issues  and  modelling  ideas  for  SBR. 
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SPACE-BASED  RADAR 
SIMULATION  LABORATORY 


1.0  INTRODUCTION 


The  Department  of  National  Defence  is  funding  a  Space -Based  Radar  (SBR) 
research  and  development  Project.  Because  of  the  complexity  of  a  Space -Based 
Radar  system  and  its  operating  environment,  it  is  necessary  to  evaluate  SBR 
performance  through  computer-based  simulation.  The  Space-Based  Radar  Project 
is  developing  an  SBR  Simulation  Laboratory  (SBRSL).  This  Simulation 
Laboratory  will  be  an  essential  research  tool,  particularly  for  system 
studies.  For  example,  one  such  system  study  might  look  at  the  effect  on 
target  detection  as  the  satellite  altitude  and  the  number  of  satellites  in  a 
constellation  are  varied.  The  SBR  Simulation  Laboratory  will  be  a  secure 
computing  facility  residing  at  Defence  Research  Establishment  Ottawa  (DREO) . 

It  will  consist  of  hardware,  a  computing  environment,  and  a  number  of  software 
application  programs.  The  Simulation  Laboratory  will  be  used  for  SBR  research 
by  SBR  Project  staff  and  private  industry  through  contracts. 

Two  software  application  programs  are  under  development.  They  are  the 
SBR  Integrated  Surveillance  and  Interception  Response  System  Simulator 
(ISIRS),  and  the  SBR  System  Simulator.  These  simulators  will  evaluate  an  SBR 
system  design  when  given  a  set  of  operating  parameters,  conditions  or 
constraints.  The  SBRSL  is  not  designed  for  real-time  analysis  or  emulation. 

These  two  simulators  will  be  used  to 

•  optimize  parameters 

•  identify  SBR  system  deficiencies 

•  evaluate  SBR  designs 

•  predict  performance  of  SBR  configurations 


The  SBR  Simulation  Laboratory  is  expected  to  be  completed  and  ready  for 
operation  in  mid- 1990. 
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2.0  SIMULATORS  UNDER  DEVELOPMENT 


Initially,  the  SBRSL  will  consist  of  two  simulators:  the  SBR  System 
Simulator  and  the  ISIRS  Simulator. 


» 


2.1  SBR  SYSTEM  SIMULATOR 


$ 


The  SBR  System  Simulator  will  simulate  the  SBR  space  and  ground 
segments.  This  simulator  will  evaluate  the  performance  of  an  SBR  system 
operating  independently  of  other  surveillance  sensors .  The  models  in  Table  1 
will  be  included. 


TABLE  1.  SBR  System  Simulator  Models 


Space -Based  Radar 

-  SBR  ground  segment 

-  SBR  space  segment 

-  SBR  communications 


Threats 

-  airborne  targets 

-  ground  jammers 

Environment 

-  surface  clutter 

-  update  simulation  time 


« 

The  simulator  will  perform  functional  simulations  in  which  the  output  is 
obtained  as  a  table  of  values  for  one  independent  variable  and  several 
dependent  variables.  The  independent  variable  could  be  time  or  some  other 
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quantity.  For  example,  a  run  could  be  submitted  in  which  the  scan  angle 
varies  from  a  minimum  value  of  20®  to  a  maximum  value  of  40°  in  steps  of  2®. 


2.2  ISIRS  SIMULATOR 


The  ISIRS  Simulator  will  evaluate  the  performance  of  SBR  working  with 
existing  and  planned  NORAD  facilities.  The  models  in  Table  2  will  be 
included. 


Table  2.  ISIRS  Simulator  Models 


Command,  Control  and  Communications 

-  Canada  Sector  Operations  Control  Centre  (SOCC) 

Surveillance 

-  ground-based  radar 

-  space -based  radar 

-  Airborne  Warning  and  Control  System  (AWACS) 

-  high-level  surveillance  systems 


Threats 

-  strategic  bombers 

-  cruise  missiles 

-  surface  jammers 

-  civilian  aircraft 


Natural  Environment 


This  simulator  will  perform  stochastic,  discrete -event  simulations  in 
which  the  output  is  obtained  as  timed  event  logs .  An  example  of  an  event  log 
is  shown  in  Table  3.  Results  may  be  obtained  through  the  repetition  of  runs 
in  a  Monte  Carlo  manner. 


i 

Table  3.  Sample  Event  Log 


t 


Time 


Source 


Event 


0:20:02 

0:23:34 


Strategic  Bomber(l) 
SBR 


Change  Course 
Target  Detect 


v. 


t 
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3.0  DEVELOPMENT  APPROACH 


The  development  of  the  SBRSL  has  been  broken  down  into  two  phases:  the 
Definition  Study  Phase  and  the  Detailed  Design,  Implementation,  Test  and 
Installation  Phase. 

3.1  DEFINITION  STUDY  PHASE 


During  the  Definition  Studies,  the  characteristics  of  the  simulators 
were  specified.  User  requirements  were  identified,  software  and  hardware 
requirements  were  established,  and  the  required  simulator  models  and 
parameters  were  determined.  Software  development  costs  and  hardware 
procurement  costs  were  estimated  and  implementation  plans  were  proposed.  A 
set  of  experiments  to  be  used  in  exercising  the  simulators  were  designed  and 
described.  In  this  phase,  no  software  was  developed  and  no  hardware  was 
purchased. 

Two  separate  contracts  were  let  to  two  companies  to  define  the  distinct 
simulators.  These  contracts  were  valued  at  $300,000  each.  The  contracts  took 
one  year  to  complete  and  finished  in  the  spring  of  1988.  The  ISIRS  Simulator 
was  defined  by  AASTRA  Aerospace  Inc.  [1],  The  SBR  System  Simulator  was 
defined  by  Canadian  Astronautics  Limited  (CAL)  [2]. 


3.2  DETAILED  DESIGN,  IMPLEMENTATION,  TEST  AND  INSTALLATION  PHASE 


The  second  phase  in  the  development  of  the  two  simulators  is  the 
Detailed  Design,  Implementation,  Test  and  Installation  Phase.  The  objectives 
of  this  phase  are  as  follows : 


•  define,  specify  and  design  the  SBRSL  and  document  all  work 

•  specify  the  hardware  requirements,  procure,  install  and  test 
the  hardware 

•  implement  the  detailed  design  of  both  simulators 

•  test  all  software 

•  deliver  a  completed  SBR  Simulation  Laboratory  to  DREO 
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One  contract  has  been  let  for  the  second  phase  (Figure  1) .  The 
contracting  team  is  as  follows: 

•  AASTRA  Aerospace  -  prime  contractor 

•  Prior  Data  Sciences  -  software  coding,  Quality  Assurance 

•  MPB  -  radar  systems  modelling 

•  GE-RCA  -  Air  Defence  Systems  modelling 


This  contract  started  in  January  1989,  and  is  expected  to  be  finished  by 
mid- 1990.  The  cost  of  the  contract  is  $1,700,000. 


Definition  Phase  Detailed  Design  and 

Implementation  Phase 

Figure  1.  Development  Strategy 
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3.3  SBRSL  DEVELOPMENT  STANDARDS 


The  Simulation  Laboratory  is  being  designed  to  allow  future  enhancements 
to  the  two  simulators  and  to  allow  additional  simulators  to  be  incorporated 
into  the  Laboratory.  To  ensure  this  flexibility,  a  rigorous  design  and 
development  approach  is  being  enforced  in  the  second  phase  contract.  The 
contract  team  is  following  the  intent  of  DoD-STD-2167A  [3].  An  Independent 
Verification  and  Validation  contractor  will  be  monitoring  the  entire 
development  process. 


3.4  SIMULATOR  MODEL  COMPLEXITY 


Upon  completion  of  the  implementation  contract,  the  SBRSL  will  consist 
of  a  set  of  models  integrated  in  a  software  framework.  This  framework  will 
allow  for  future  software  upgrades,  enhancements,  and  additional  simulators. 
The  models  being  developed  in  this  phase  will  be  simple.  This  is  being  done 
to  provide  users  with  the  capability  to  simulate  a  complete  SBR  System, 
although  not  at  a  detailed  level.  For  example,  the  simulator  will  model  radar 
performance  using  the  radar  equation.  Detailed  simulations  of  the  processing 
of  video  signals  will  not  be  included.  This  capability  could  be  added  in  the 
future,  however,  either  by  providing  the  necessary  models  for  the  SBR 
simulator,  or  by  creating  another  simulator  within  the  existing  framework.  It 
is  anticipated  that  additional  work  will  be  carried  out  to  incorporate  more 
detailed  models  of  various  components.  These  upgrades  will  occur  as  the  need 
arises . 


3.5  DESIGN  PHILOSOPHY 


The  two  simulators  are  being  designed  and  implemented  using  object- 
oriented  techniques.  A  brief  description  of  some  object  oriented  terminology 
follows  to  provide  insight  into  this  design  approach. 

An  object  is  a  well-defined  data  structure  linked  with  a  set  of 
operations  that  describes  specifically  how  that  data  can  be  manipulated.  Only 
these  operations  can  manipulate  the  data.  These  operations  are  called 
methods.  An  object's  data  representation  is  hidden  from  the  users.  An  object 
is  requested  to  invoke  one  of  its  methods  by  sending  it  a  message.  This 
object  is  called  the  receiver.  The  message  describes  to  the  receiver  object 
what  operation  is  to  be  performed.  The  message  may  contain  arguments  to  be 
passed  to  the  operation.  The  message  describes  what  operation  is  to  occur, 
not  how  it  will  occur.  This  same  message  may  be  interpreted  differently  when 
sent  to  other  objects. 
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Objects  are  grouped  together  into  classes.  The  class  provides  all  the 
information  necessary  to  construct  and  use  objects  of  a  particular  kind. 
Classes  enable  the  management  of  collections  of  objects.  A  class  can  inherit 
methods  from  superclasses  (those  above  it),  and  its  methods  can  be  inherited 
by  subclasses  (those  below  it).  An  example  of  classes  is  given  in  Figure  2. 
Sports  car  is  a  subclass  of  Automobile.  Transportation  is  a  superclass  of 
Automobile  and  Aircraft.  Automobile  and  Aircraft  can  inherit  all  the  methods 
of  Transportation  [4] [5] . 

The  nature  of  the  SBR  and  ISIRS  simulators  leads  naturally  to  object 
oriented  design.  The  various  components  can  be  well  defined  by  objects  and 
classes  of  objects.  The  models  in  the  simulators  are  defined  as  a  network  of 
objects  that  interact  via  messages.  This  design  philosophy  will  produce 
structured  and  modular  simulators. 


Figure  2.  Example  of  Object  Oriented  Classes.  Sports  car  is  a  subclass  of 
Automobile.  Transportation  is  a  superclass  of  Automobile  and 
Aircraft.  Automobile  and  Aircraft  can  inherit  all  the  methods  of 
Transportation . 


8 


3.6  HARDWARE  AND  COMMERCIAL  SOFTWARE  PACKAGES 


The  hardware  for  the  SBRSL  consists  of  a  SUN-4/260  compute  server  rated 
at  10  MIPS,  with  two  SUN  4/110  diskless  nodes  rated  at  7  MIPS  each,  all  linked 
by  an  Ethernet  network.  The  compute  server  has  the  following  characteristics: 

•  8  MBytes  of  RAM 

•  688  MBytes  of  fixed  disk  storage 

•  a  floating-point  accelerator 

•  60-MByte,  1/4- inch  tape  cartridge 

•  19- inch  colour  monitor,  resolution  1152  by  900  pixels 


The  diskless  nodes  each  have 

•  a  colour  monitor  identical  to  that  of  the  server 

•  8  MBytes  of  RAM 

•  a  floating-point  unit 

The  SBRSL  hardware  also  consists  of  a  Sun  LaserWriter  II  and  a  Seiko 
CH5504-PM3  colour  printer. 

Databases  and  graphics  software  are  not  being  designed  specifically  for 
the  SBRSL  as  it  is  felt  that  this  would  be  an  inefficient  use  of  manpower. 
Suitable  commercial  software  packages  are  available.  A  database  management 
system  is  necessary  in  the  SBRSL  because  large  amounts  of  data  will  be 
generated.  It  is  imperative  that  there  be  a  structured  means  of  maintaining 
this  information.  The  two  simulators  will  provide  the  users  with  the 
capability  to  display  graphics  such  as  parameter  barcharts  and  global  maps. 

The  UNIX  operating  system  will  be  used.  The  development  language  will 
be  C++. 


3.7  PROTOTYPING 


Prototyping  will  be  used  for  several  aspects  of  the  simulator. 
Prototyping  is  the  process  of  developing  a  scaled-down  version  of  a  system  to 
make  the  development  of  the  full-scale  system  easier.  The  object-oriented 
approach  being  used  in  the  design  of  the  SBRSL  will  make  the  prototyping  more 
flexible.  The  prototyping  activity  will  be  used  to  validate  requirements. 
Should  the  requirements  be  changed  after  using  the  prototype,  the  change  can 
be  reflected  in  the  prototype  with  less  effort  than  would  be  required  to 
change  the  full-scale  software.  The  knowledge  gained  when  designing  the 
prototypes  will  be  used  to  develop  a  more  suitable  SBRSL  design  than  would 
otherwise  be  possible.  One  aspect  of  the  SBRSL  that  will  be  prototyped  is  the 
user  interface. 
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3.8  STRUCTURE  OF  THE  STATEMENT  OF  WORK 


The  Statement  of  Work  (SOW)  breaks  the  second  phase  contract  down  into 
six  tasks.  This  enables  the  work  to  be  done  in  stages,  allowing  the  SBR 
Project  Office  visibility  and  input  into  the  development  of  each  simulator. 
Each  task  is  closely  monitored  to  ensure  that  a  useful  SBRSL  results.  It  is 
easier  and  less  expensive  to  change  a  design  while  still  in  the  requirements 
or  preliminary  design  stages.  It  is  much  more  costly  and  difficult  to  change 
a  design  at  the  implementation  or  test  stages.  The  SOW  was  structured  with 
this  in  mind.  There  will  be  major  milestone  meetings  at  the  end  of  every 
task.  The  SOW  consists  of  the  following  tasks: 

Task  1  -  Requirements  Review  and  Implementation  Plan 

This  task  is  broken  down  into  the  following  subtasks: 

•  Review  the  work  done  in  the  Definition  Study  phase. 

•  Identify  the  requirements  of  the  SBRSL. 

•  Provide  an  Implementation  Plan. 


Task  2  -  Hardware  Implementation 

This  task  is  broken  down  into  the  following  subtasks: 

•  Review  the  hardware  configurations  proposed  in  the 
Definition  Study  phase. 

•  Recommend  and  justify  a  single  hardware  configuration. 

•  Purchase  the  hardware. 


Task  3  -  Detailed  Specification  and  Design 

The  work  in  this  task  will  create  a  detailed  design  of  the  two 
simulators  that  will  initially  make  up  the  SBRSL. 

r’ask  4  -  Implementation  of  the  Detailed  Design 

The  work  in  this  task  will  involve  the  coding  of  the  detailed 
design. 


Task  5  -  Integration  and  Test  of  the  Software 

This  task  is  broken  down  into  the  following  subtasks : 

•  Integrate  all  software  modules  that  were  coded  and 
tested  in  Task  4. 

•  Integrate  all  modules,  testing  each  portion 
as  it  is  included. 


Task  6  -  Acceptance  Testing  and  Delivery  of  the  SBRSL 

Formal  acceptance  testing  of  the  two  simulators  will  occur  in  this 
task.  As  well,  the  contractor  will  deliver  all  hardware  and  software  to 
DREO. 
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4.0  OVERVIEW  OF  THE  SIMULATION  LABORATORY  DESIGN 


The  SBR  System  Simulator  and  the  ISIRS  Simulator  have  similar  designs. 
The  steps  taken  by  the  user  to  run  either  the  SBR  System  Simulator  or  the 
ISIRS  simulator  will  be  the  same.  The  running  of  each  simulator  is  broken 
down  into  five  basic  operations: 


•  Simulation  Configuration 

•  Run  Planning 

•  Run  Operations 

•  Data  Analysis 

•  Data  Output 


The  following  descriptions  of  these  operations  provide  some  insight  into  the 
capability  of  the  system. 


4.1  SIMULATION  CONFIGURATION 


This  operation  will  allow  the  user  to  define  objects  (models)  and  their 
parameters  and  messages.  It  also  allows  the  user  to  specify  which  models  will 
be  combined  to  build  the  simulation  configuration.  It  is  not  necessary  to  use 
all  models  listed  in  Tables  1  and  2  when  building  a  simulation  configuration. 
This  allows  the  user  the  flexibility  to  create  simple  or  complex 
configurations . 


4.2  RUN  PLANNING 


This  operation  will  provide  the  user  with  the  ability  to  specify  and 
manage  the  data  to  be  used  by  the  simulation  run.  This  data  will  be  organized 
into  several  datasets: 

•  initialization  datasets  -  specify  initial  parameter  values 
for  the  run 

•  recording  datasets  -  specify  the  events  and  parameters  that 
can  be  recorded  during  a  run 

•  console  datasets  -  specify  the  layout  and  content  of 
displays  used  for  monitoring  interactive  runs 
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4.3 


RUN  OPERATIONS 


This  operation  will  load  models,  initialize  the  simulation  and  start  the 
run.  As  well,  the  user  will  be  able  to  control  the  execution  of  batch  and 
interactive  simulation  runs,  and  to  examine  the  status  of  these  runs. 

4.4  DATA  ANALYSIS 


This  operation  will  provide  the  user  with  the  ability  to  analyze  data 
recorded  during  runs  and  to  correlate  data  collected  from  various  runs.  It 
also  will  provide  the  user  with  the  capability  to  display  data  on  the  screen 
or  to  obtain  a  hard  copy.  It  will  be  possible  to  load  data  into  user-defined 
data  tables  and  to  store  data  in  graphic  metafiles.  A  metafile  is  a  file  that 
contains  device - independent  graphics  instructions.  The  graphics  stored  on  the 
metafile  can  be  retrieved  and  displayed  on  any  device.  The  user  will  be  able 
to  display  plots ,  barcharts ,  tables  and  maps . 
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5.0  THE  FUTURE  OF  THE  SBR  SIMULATION  LABORATORY 


The  SBR  Simulation  Laboratory  will  consist  of  two  simulators  at  the 
completion  of  the  second  phase  of  work.  Future  enhancements  to  these  two 
simulators  will  be  desirable  to  have  more  detailed  models  of  SBR  operations. 

As  well,  other  simulators  may  be  integrated  into  the  SBRSL.  For  example, 
mechanical  stability  models,  antenna  simulation  software,  thermal  deformation 
models,  an  IR  simulator,  and  an  EHF  Satcom  simulator  are  possible  additions. 

The  SBRSL  is  seen  as  an  evolving  simulation  laboratory.  Researchers  and 
contractors  will  study  various  design  issues  and  modelling  ideas  for  SBR 
covering  a  wide  range  of  parameters  and  conditions. 

It  will  provide  confidence  that  the  SBR  concepts  under  consideration  can 
meet  the  needs  of  DND,  and  that  the  R&D  supported  by  the  SBR  Project  will  have 
beneficial  effects  on  an  operational  SBR  system. 
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